Forms or dialogs have become an essential component in modern computers and software applications. Traditionally, such forms have been hand-encoded by a programmer. Such forms may be dynamic (automatically updated in response to answers input by a user) or static. Although the generation of the form description, and the layout of component elements is a relatively straightforward task, the generation of the code which controls the dynamic behaviour of the form can be far from straightforward. Even editing a static form, if the form is sufficiently complex, may be far from straightforward. The coding itself is then used to generate script subsequently interpreted by the viewing application, for example, Java™ or Javascript™ generation in a web browser.
When forms are hand-encoded, the interaction between elements may require much thought by the programmer. There may be subtle, yet significant consequences of selecting one option over another. The change may cause other elements to become available, or not, which in turn affects yet other elements. Thus, a simple change may have a ripple effect throughout the whole form.
A form viewed through a web browser may contain various elements which need information to be input or selected by a user. Depending on the information content generated by and required by the form, selection of various elements may enable and disable subsequent questions in earlier or latter parts of the form. (This situation is frequently encountered when using a document generation program.)
One example of a known automated document generation program is that described in WO01/04772. In this system, a server computer runs a document generation program and is capable of communicating with local or remote client computers over a local area network (LAN) or a wide area network (WAN), such as the Internet. A standard document, comprising various items of known information and associated logical rules, is first translated into a form suitable for processing by the document generation program. When instructed to generate a customised document, the server first generates one or more web pages which are sent to client computers for user input of the further information required to evaluate the logical rules. Users may then submit the further information to the server. Once all the required further information has been captured, the server generates a customised document on the basis of the standard document and received further information.
When information is captured, the transaction values entered by the user will be substituted for the various variables in the standard document. One difficulty in capturing such transaction values using web pages or web forms, is ensuring that the page or form prompts the user for the correct information. This is a particular problem when, in a series of related questions, some of the information needed is dependent on an answer to a previous question. Omitting such dependencies when encoding the script from which the standard document is generated leads to the behaviour of the form being incorrect.
FIGS. 1a to 1d show simple examples of a form having question dependencies, where questions are enabled and disabled in response to answers provided by a user. The first question asked relates to whether a buyer is a private individual, a registered company or a charity. Depending on the answer provided to this question, the user is then prompted for a private address or a business address. In addition, if the buyer is a registered company or charity, the company or charity number is requested. If the buyer is a private individual, then the name of a guarantor may be requested.
The form illustrated in FIG. 1a has four possible states dependent upon the answer to the first question (status of buyer):
1a: private individual but no guarantor;
1b: private individual and a guarantor;
1c: registered company; and
1d: registered charity.
Hence, the question regarding private address will only be enabled if the user selects the status of the buyer as being a private individual. Similarly, the business address question will only be enabled if the user selects the status of the buyer as being a registered company or charity. Consequently, both of these questions are dependent on the status of the buyer. Both of these selections occur as a direct consequence of any change to the status of the buyer. In the following discussion, functions which update questions as a direct consequence of a change of state are referred to as direct functions. Any element which is directly affected by such a function is termed a direct element.
However, the status of the buyer can affect questions beyond such direct consequences. For example, in FIG. 1a, the buyer is selected as being a private individual, and a subsequent question asks whether the buyer has a guarantor. In this case the answer is no. However, in FIG. 1b, the option for the buyer to have a guarantor is selected as “yes”, and hence the question requesting the name of the buyer's guarantor is enabled. In this situation therefore, the enabling of the buyer guarantor question is a direct consequence of the answer to the buyer status question, and the enabling of the guarantor name question is a direct consequence of the selection of whether the buyer has a guarantor or not. However, there are indirect consequences to the selection of the buyer's status.
If, subsequent to the selections made in FIG. 1b, the user discovers that, in fact, the status of the buyer is a registered company, the question regarding buyer guarantor name is no longer necessary. Therefore, if the status of the buyer is selected as “registered company”, the questions regarding business address and company number must be enabled, and the buyer guarantor name question disabled. Both the business address and company number questions are a direct consequence of the change. However, the disabling of the guarantor name question is an indirect consequence of the change. Such an indirect consequence may be termed an indirect function. Although there is no single function to change the guarantor name when the private buyer option is selected, the combination of direct functions necessary to enable this change is effectively an indirect function. The order in which the direct functions are executed is termed an invocation sequence.
Using prior art methods, such a form must be hand encoded as a whole: it cannot be considered as a series of individual questions. The form is considered as a complex series of IF, THEN, ELSE statements, rather like a decision tree. In doing this, it is necessary to consider, for each question, the effect of all possible answers to that question on each subsequent question asked. This results in the coding of each question being interrelated to the coding of each other question: all of the direct and indirect consequences of changing the answer to a question must be considered.
Aside from being highly complex and time-consuming, if the form is subsequently edited to add or remove questions, the entire form must be re-encoded, as any additional coding for a question must be interrelated with the coding for all other questions. This is the case even if a question is added at the end of the form. The major drawback of using such complex code, other than the programmer time involved, is that complex code lines are prone to error and debugging such code is also time consuming and difficult.
It is extremely difficult to use this approach with forms that are automatically generated by various applications, including browser and web-based applications, due to the complexity and time-consuming nature of the encoding method. Even static forms must be completely re-entered if additional questions are added. Even if such a form is successfully encoded, a large amount of complex code must be exported to a form renderer, such as a web browser, in order to be viewed. This requires large computing resources and data transfer capabilities, making use of the form relatively slow and inefficient.